II.FHIR Resource

03 FHIR Resource初探, Cardinality, Flags, Reference與Extension

上一篇文章開始談到了關於FHIR的一些概念架構，今天要來談一下FHIR的基本單位 - Resource

誠如先前所提到的，各種用途的單張或是資訊表單都是由不同層級跟用途的Resource所構成的，
而FHIR標準和各層級的IG限制了這些Resource的內容與用途

但各種表單中，會非常高頻率使用的Resource大致上是：

Patient -> 病患的基本資料

Observation -> 診斷或觀察

Condition -> 病症、症狀

以及描述機構、診間等硬體設備的

Encounter -> 門診別

Organization -> 機構資料

以上算是筆者個人使用經驗上非常常用到的幾個跟醫學資料有相關的Resource，

試設想，光是有以上5項就能簡要說明這個病患看診的過程、場所、紀錄與診斷了，
如果再加上其他Resource可以將這個過程描述的更加詳細。

但Resource作為FHIR的基本元素，自然不會只有提供給醫療資料使用的種類，
其他你不會在正常的單張看到但是你會很常看到的Resource：

StructureDefinition -> 描述實作指引IG內容的Resource

CapabilityStatement -> 描述實作指引IG的能力適用範圍的Resource

StructureMap -> 描述FHIR資料映射轉換關係的Resource

CodeSystem -> 描述FHIR可用的代碼系統的Resource

ValueSet -> 描述一些CodeSystem的集合的Resource

說了這些Resource，接下來要來看的是該怎麼閱讀這些Resource所需要呈現的資訊或限制

以最多人拿來做教學範例也最基本的Patient Resource來看，

https://www.hl7.org/fhir/patient.html

首先先看8.1.3 Resource Content列表中的Structure，裡面以樹狀圖的方式描述了Patient的組成

首欄Name為這個屬性內容項的名稱，

第二欄Flags則代表了這個屬性內容項的特性，例如Σ, ?!, C等，以下概述說明各項的代表意義：

 Σ: Summary，代表這個屬性項是一個集合的代表，
使用者可以透過fhir search(後面會提到)的_summary來取用這個資源集合的子集，
 目的是為了降低使用者透過FHIR Server查詢資源時造成的負擔，並且可以更有效率的完成需求。
 
 C: Constraint，代表這個屬性項會受到某個Constraints(限制)影響，
Constraint在實作指引IG中扮演了非常重要的角色，
 IG會透過Constraint來限制使用者填入該欄位的資料範圍或類型，
Constraint通常可以在IG的Resource Profile中的下方找到
 驗證FHIR格式時，驗證器會去透過Constraint來測試填入的欄位是否正確，否則回報Error。
 
 S：Must Supported，必須支援欄位，若屬性項有這個標示代表填寫該欄位必然具有某些現實的可支撐性，
詳細的定義不為FHIR所規範，以白話來說，就是這個欄位本身是與現實的資料有所連結的，
像是病患的醫療資料，醫事場所的代碼等，且該屬性項會受到實作指引IG的創建者的使用。
 
 NE：No extensions allowed，不允許Extension引入，代表這個屬性項不允許使用Extension，
這個很少見，筆者在實作研究的過程中幾乎沒有遇到過。
主要會用在基礎元素(infra)的Resource定義上，實務上不太會遇到。
 
 ?!：is Modifier，代表這個屬性的改動會對整個Resource造成重大影響，
或是根本上的改變Resource所要表達的意義，最簡單的就是每個FHIR Resource中的擁有的Status，
描述的是關於這個Resource的狀態，一個醫療事件是已完成或是正在進行會對各項應用的判斷產生影響，
因此會有?!項的引入
 
 N：Normative，這個只會出現在Resource最上層的Flags上，
代表現在這個Resource已經是完整可投入使用的，但在IG Profile裡面不太會出現。
 
第三欄Card.，全名為cardinality，中文翻譯稱作基數，這個欄位代表了這個屬性項的數量範圍，
基本型態以X..Y表示，代表最少要有X個，最多有Y個，大多數會看到的表示法不外乎4種：

 0..1：這個屬性項容許最少0個，最多1個，這個屬性項非必填，但是若要填入的話最多就是一個。
 1..1：這個屬性項容許最少與最多都是1個，這個屬性項必填，且只能填一個。
 0..：這個屬性項容許最少0個，最多個，這個屬性項非必填，但要填的話不限制上限數量。
 1..：這個屬性像容許最少1個，最多個，這個屬性項必填，但但要填的話不限制上限數量。
 
第四欄Type，表達的是這個屬性項的資料型態，在datatypes.html可以找到關於這個型態應該包含的內容跟子屬性項，
實務上會比較建議這裡可以參考IG Profile提供的範例，會比較容易了解應該填入的資料型態。
 
https://hl7.org/fhir/R4/datatypes.html

比較需要注意的是CodeableConcept與Coding這兩個資料型態，

CodeableConcept包含了coding與text，但coding本身需要system代碼系統，
code代碼組合而成，初學者會相對容易搞混。

另外需要注意的是Reference這個資料型態，這個資料型態代表這個屬性項必須是引用其他資源的Resource ID，

由於FHIR的Resource各自有相依關係，如檢查報告勢必會連結上指定的病患，
因此若在一個Resource中有Reference存在，

該Reference必須要存在於Bundle、Composition等上層Resource或FHIR Server中，
若是找不到會回報Error，

此外，Reference的表示方法是ResourceType/Resource ID，如Practitioner/practitionerID。

再來要提到比較細節的地方是Extension，前面多次提到過，Extension是FHIR中容許自訂屬性項的範圍，

舉個例子：(modified from Outburn.health)

{
 "resourceType": "Patient",
 "name": [
   {
     "use": "official",
     "family": "John",
     "given": ["Doe"]
   }
 ],
 "extension": [
   {
     "url": "http://test.fhir.org/fhir/StructureDefinition/preferred-name",
     "valueString": "Tony Stark"
   }
 ]
}

這是一個簡單的Patient Resource，裡面僅包含了name這個屬性項，

然而，extension內又引入了一個url，這個url代表了該病患的偏好名稱，

因為偏好名稱並沒有正式定義於HumanName.use
(usual | official | temp | nickname | anonymous | old | maiden)

但我想要對這個病患的名稱做補充說明，於是我引用了一個url與value來表達這個病患的偏好名稱，

在實作指引IG設計上，有些IG發佈者會限定使用者不可以使用非IG定義的extension，
並且可能會要求使用指定的extension url，
這是由於FHIR本身遵守80:20原則，若某個特定用途的IG需要特殊的欄位，
IG發佈者會要求使用者使用以達到IG設計所需的資料項。

有一個很容易被忽視的東西是，在閱讀Profile或StructureDefinition的時候，
你可能會看到modifierExtension這個屬性項，
他跟Extension很像但在意義表達上完全不同，

modifierExtension想要表達的是使用者"必須不可忽視"的要素，
如果忽視了這個定義會對醫療行為或臨床決策造成莫大的影響，

以血壓BP這個Resource來舉例，
若modifierExtension內有標註該次測量的血壓結果並不完全可靠，
該Resource中的舒張/收縮壓數據只能做為參考，
當閱讀者或醫事人員忽視了這個屬性項，他們可能會將這個結果認為是完全可用的，進而做出錯誤的診斷或處方。

值得注意的是，modifierExtension通常是依附於某個屬性項上，並不是完全影響整個Resource的可用性，
以這個例子來說，我提交的血壓BP Resource中可能只有一筆被標註為不完全可靠，
對於臨床判斷來說，其他的數據仍然具有可信度。
實務上使用modifierExtension的機會很少，IG也很少要求使用或定義，
但這兩者在名稱上會滿容易搞混的，在此說明。

今天談的東西大多都是定義面的東西，有點硬叩叩，
明天來大概談一下Resource的範圍大概有多大。